Subject: Comments on the CD1.7 draft (2) - given id of 99-xxxx

Author: Robert Jones, email: 100621.553@compuserve.com

References:

1. Committee Draft 1.7 for the proposed revision of ISO 1989:1985, COBOL standard - PDF version. I use Adobe Acrobat Reader, version 3.

2. 99-0519 Comments on the CD1.6 Draft (2) by me.

3 99-0560 Comments on the CD1.7 Draft (1) by me.

Comments:

1 Source text manipulation, 7.1.1.4, Text words, page 41

revisited from item 6 of 99-0519 and copied below.

Item 1, second sentence, I am not sure about this. What is the position when matched or unmatched parentheses occur in alphanumeric and national literals, or indeed any separator occurs within such literals. Maybe it would be better to resequence items 1, 2 and 3 as items 2, 1 and 3 in order of application. I have to think more about the use of the term "text-word". Also refer to 8.3.2 Separators.

Perhaps item 3 should also include the word "REPLACE".

***************** original above

(I sent an email to Don Schricker suggesting that it would probably be necessary to add the phrase "except for delimited literals" to the second sentence of item 1.) Maybe that is all that needs doing. The reason I think it needs doing is that while "7.1.1 Text manipulation elements" refers to "8 Language fundamentals", the way 7.1.1.4 is written appears to override the way that reference states that parentheses are to be handled.

Maybe "7.1.1.4 Text-words, item 3" should have the same exclusions as syntax rule 12 of the COPY statement.

2 COPY Statement, 7.1.2.2, General format, page 48

revisited from item 25 of 99-0560.

I should have specified "literal-3" and "literal-4" rather than "literal-1" and "literal-2".

3 COPY Statement, 7.1.2.2, Syntax rules, page 48

revisited from item 29 of 99-0560 and copied below.

(I now think that the only reason sole commas and semicolons are disallowed is because of their use as separators in the replacement process.)

(I still can't make up my mind whether the following is worth considering.)

Rule 14, I think there is a case for also excluding a sole period as well as sole separator commas and semicolons. After all, a compiler would not be able to make much sense of the result. A single separator space could also be reasonably excluded, as perhaps could any number of spaces with no other characters. Is the term separator needed in the rule? Arguably single spaces, parentheses, quotes and apostrophes are already excluded from having any effect by the specification of "7.1.1.4 Text-words", though they could still be present.

Consider other single characters that should not be allowed, e.g. hyphens, ampersands, quotes, apostrophes, plus and minus signs, relational operators. Should any single characters be allowed? Maybe only single characters not in the COBOL character repertoire should be allowed. Should character strings representing single reserved or context sensitive words be allowed (there may be good cases where such words should be allowed, though I haven't yet thought of any)? Are there other multiple groupings of characters that should not be allowed, for example two colons, two asterisks, and the relational operators ">=" and "<="?

There is presumably a limit on how much protection against misuse that the standard should provide. Also, it may be that some replacing operations need to be able to change certain items on a limited scale that would not be acceptable if done globally.

***************** original above

(I think the purpose of using the term "separator" as an adjective in conjunction with "space", "comma" and "semicolon", is to ensure that the use of those terms is clearer, though even 8.3.2 is internally inconsistent.)

Consider the significance of the presence of a comma and a space or any number of either in any sequence in pseudo-text-1 in respect of the way they are handled in general rule 8. Same applies to semicolons and space, or any combination of all three. Maybe what should be disallowed in rule 14 is any combination of any number of all three when no other characters are also present.

4 Compiler directing facility, 7.1.1.3, Pseudo-text, page 45

It could be helpful to state that pseudo-text containing only spaces, commas and semicolons is effectively empty when used as the matching operand. Or perhaps it would be better in "7.1.2.2 COPY statement syntax rule 14" and "7.1.3.2 REPLACE statement syntax rule 11".

5 7.1 Text manipulation, page 45

Fifth block of text, 2nd line on page 45, commencing "Other indicators ...", replace "by" by "be".

6 Compiler directives, 7.2.2, Syntax rules, page 54

Rule 5, replace all three instances of "initiator" by "indicator". Also split "iscomposed".

7 SOURCE-FORMAT directive, 7.2.15.2, General rules, page 68

Rules 3 and 5, replace "period" by "separator period".

8 8.3.1.2.2.2, Floating-point numeric literals, page 88

Item 1, replace "spaces" by "intervening space characters".

9 8.3.2 Separators, page 94

I am currently reviewing this, I think that there is a certain amount of circular logic and inconsistency with regard to the terminology of separator spaces and their possible logical equivalents. Also that some aspects that I think are implied would be better for being stated explicitly. I think that the term "space" would often better be replaced by "space character" or "character space". Also that references to "5.1.7 Punctuation" and "6. Reference format" would be helpful in the introduction. A reference in 5.1.7 to 8.3.2 would also be helpful.

However, I don't feel that my detailed comments are worth consideration yet.

10 Class condition, 8.8.4.1.3, General rules, page 142

Rule 3b, replace "A, B, C, ..., Z, space" by "A, B, C, ..., Z, and space" and do the same for "a, b, c, ..., z, space".

11 OPTIONS paragraph, 11.9.2 Syntax rules, page 196

Rule 1, replace "periods" by "separator periods".

12 SPECIAL-NAMES paragraph, 12.2.6.2, Syntax rules, page 209

Rule 28, replace "The period" by "One of the separator periods" as is done in "11.9 OPTIONS paragraph" and for the same reason, i.e. there are two separator periods in the general format, one after the paragraph header and one after the paragraph text.

13 13.3.4, File description entry, page 244

Last sentence of first para, replace "period" by "separator period".

14 COLUMN clause, 13.16.16.3, General rules, page 289

Rule 2a2, I don't understand this, perhaps it should read "The interim size is increased, if necessary, to equal an integral column number and the printable item is space-filled accordingly.".

15 PICTURE clause, 13.16.41.3, General rules, page 337

Rule 13, dealing with the comma symbol, the word "symbol" is misspelt.

16 Declaratives, 14.5.2, Paragraphs, page 398

Replace "period and a space" by "separator period".

17 14.6.3.1, Imperative statement, page 400

Last para, replace "period" by "separator period".

18 IF statement, 14.10.18.2, Syntax rules, page 466

Rule 3, replace "period" by "separator period".

19 A.1.1.1, Communication description entry, page 658

First para, last sentence, replace "period" by "separator period".

20 E.1, Archaic language elements, page 843

Item 3, second and third sentences, replace "period" by "separator period". While this is a descriptive explanation, I think that use of the technical term separator period is preferable, it certainly makes searching in computer documents easier.

21 Index, Period, page 862

Perhaps a reference also to page 94 for separators would be helpful.

22 Index, Separators and Space, pages 865-865

Could usefully also refer to page 34.

23 Index, Pseudo-text delimiter, page 863

There are separate entries for "Pseudo-text delimiter" and "Pseudo-text delimiters". I think that these should be combined.